A mobile or multi-homed host may have to change its Layer 3 network access point (i.e., IP address) while running a content retrieval session, e.g. while the client is retrieving data from a remote server. Such an interface change may be desirable because the “new” interface has higher link quality or encounters lower network congestion than the “old” interface. The interface may also have to change when the user moves from the coverage area of one network to that of another.
For the client's new interface, a different server may be better suited to deliver the data than the server sending the data to the host's old interface. This may be due to the closer proximity of the new server to the client's new interface. It is also possible that the network connecting to one of the interfaces holds an application layer proxy but the network supporting the other interface does not hold such a proxy, or it holds a different proxy. While such proxy information may be pre-configured on the mobile/multi-homed host, the remote address used for content retrieval has to change when the interface changes.
For at least these reasons, it is desirable to provide capabilities to change the server delivering the content together with the interface used by the client for content retrieval.
Content retrieval applications typically use stream-oriented transport protocols such as TCP, SCTP or MPTCP, which connect the client to the content server and ensure reliable and in-order delivery of the content. When TCP is used as the underlying transport protocol, the transport connection cannot be migrated to a different interface without disrupting the superseding client-server session. When SCTP is used, the client can migrate the traffic flow from the old to the new interface. However, it is not possible to change the server at the same time, since the SCTP control block on the old server holds connection-specific information which is not shared with the new server. The same problem arises if MPTCP is used for the connection. Further, SCTP and MPTCP are not generally supported on the Internet.
There are several mobility/multi-homing protocols that accommodate the functionality of session endpoint migration on layer 3 and are therefore transparent to transport and application layers. Examples are Mobile IP protocol family, SHIM6 and LTE. Some of these solutions require additional network nodes such as home agents or specialized gateways (MIPv4, MIPv6, DSMIP, PMIP, LTE). Unfortunately, none of these solutions permits the content server to be changed during ongoing data retrieval.
There are proposals referred to as content-centric networks (e.g. Jacobson et al., “Networking Named Content”, CoNEXT '09, Proceedings of the Fifth International Conference on Emerging Networking Experiments and Technologies), which permit mobility/multi-homing and content-source migration during a content-retrieval session. These proposals, however, are not compliant with the present IP-layer and transport-layer protocols. For the same reason, they are further not compliant with the existing network infrastructure or Internet.
Application-layer solutions exist wherein attachment-point changes and server changes are built into the client application itself. Such applications can stop the data transfer midway, terminate the corresponding transport connection, re-establish a new transport connection and request the remaining data from the same or from a new server. While these solutions may be tailored to the specific application layer protocol as well as the data type of the content, they need to be implemented by every client application separately. This is very cumbersome and, inherently, does not support existing or legacy applications.
Unfortunately, while several content retrieval techniques exist to change the server delivering the content and/or the interface used by the client for content retrieval, none of these techniques is capable of supporting existing client applications while maintaining compliance with existing and evolving transport protocols.